1. Field of the Invention
This invention generally relates to the field of streaming and more specifically to secure IP-based streaming.
2. Description of Related Art
As the use of the Internet has increased over recent years, so has the exchange of information and ideas. File sharing, in particular, has enjoyed increasing popularity. Initially, file sharing was implemented using FTP and gopher. Then, as the use of TCP/IP and the Web increased, users turned to downloading files using web browsers. Today, the use of streaming has gained prevalence as it allows a user to simultaneously download and experience a media file at the same time. However, the growth of the Internet has posed some interesting obstacles in the field of access control of protected content. As users increasingly send and receive files quickly and in great quantities, access control can take a back seat to the free flow of information. This created a need for secure streaming of protected content. Secure streaming, however, comes with drawbacks.
FIG. 1 is a block diagram illustrating the overall system architecture of a typical prior art system for secure streaming. A streaming server computer system 108 provides media files, such as MPEG 2 video files, for streaming to clients. A content mastering system 110 encompasses the functions of a system for creating, authoring and providing media files to the streaming server 108. Server 108 streams the provided media files over a network 106, such as the Internet. A user 102 utilizes a client computer system 104 (such as a home personal computer) to receive the streaming media files from server 108 via network 106. The computer systems of client 104, server 108, content mastering system 110, as well as the network 106, are described in greater detail below.
A well-known approach to the problem of secure streaming is described in FIG. 2. FIG. 2 is a functional diagram illustrating the overall process of a prior art system for secure streaming. FIG. 2 shows an encoded (i.e., compressed), media file 202 comprising an encoded content data portion and an associated plain metadata portion. Media file 202 is an MPEG 2 video file, a Windows Media Player video file, a QuickTime video file, an MP3 audio file or any other encoded media file that may be streamed. On the content mastering system 110 (see FIG. 1), an encryption module 204 reads the media file 202. The product of module 204 is media file 206 containing plain metadata and encoded/encrypted content data.
Subsequently, streaming server 108 reads media file 206. Streaming server 108 is the Windows Media Streaming Server, the QuickTime Streaming Server, the Darwin Streaming Server or any other server capable of streaming media files over a network. Streaming server 108 divides media file 206 into a finite number of data packets, which are then streamed to client 104 over network 106. On client 104, a streaming client 209 receives the data packets. Then, decryption/decoding module 210 processes the data packets. The product of module 210 is a media file 212 containing plain content data. Media file 212 is then provided to renderer 214, which plays or reads the media file 212.
FIG. 3 is a flowchart depicting the operation and control flow of the overall process of the prior art system of FIG. 2. On the content mastering system 110 (see FIG. 1), the control flow of FIG. 3 begins with step 302 and flows directly to step 304. In step 304, the encoded media file 202 (see FIG. 2) comprising an encoded content data portion and an associated plain metadata portion is provided to the encryption module 204. In step 306, module 204 encrypts the content data portion of media file 202. Consequently, media file 206 containing plain metadata and encoded/encrypted content data is produced. In step 308, the media file 206 is provided to streaming server 108. In step 310, the streaming server 108 divides the media file 206 into a finite number of data packets and streams the data packets to client 104 via network 106. In step 310, the streaming server 108 also sets streaming parameters in accordance with the metadata in encoded/encrypted media file 206
On the client 104, in step 312, the streaming client 209 receives the data packets via network 106. In step 314, decryption/decoding module 210 decrypts and decodes the data packets received. The product of step 314 is a media file 212 containing plain content data. In step 316, the media file 212 is provided to renderer 316, which renders the content data in the media file 212. In step 318, the control flow ceases.
The approach described in FIG. 2 and FIG. 3, however, has its drawbacks. One drawback is that the encryption process of step 306 (see module 204) and the decryption process of step 314 (see module 210) must be format aware. That is, the encryption process and the decryption process must possess information identifying the media format of the media file 202. On the content mastering system 110, the encryption process of step 306 identifies the media format of the media file 202 by reading the associated metadata of media file 202. Likewise, on the client 104, the decryption process of step 314 identifies the media format of the media file 202 by reading the associated metadata of media file 202 as contained in the data packets sent to client 104. The format dependant character of the prior art process is disadvantageous because it decreases the compatibility of the system. In addition, the usability of the system is limited as new formats come into common use.
Another drawback of the prior art system is that the quality of the media file at the client 104 may decrease as data packet loss occurs. If a block cipher encryption is used in the encryption process, data packet loss during the streaming process may negatively affect the quality of the media file data received by the client 102. This is disadvantageous, as high quality streaming media is desirable. Yet another drawback of the prior art system is that repackaging of the content of the data packets is necessary when the encryption process modifies the size of the content data. This is disadvantageous as it adds another time and resource consuming process to the system. Therefore a need exists to overcome the problems with the prior art as discussed above, and particularly for a way to efficiently stream data securely.